REMARKS 

In response to the Office Action mailed January 26, 2007, Applicant respectfully 
requests reconsideration. Claims 1-3, 5-12, 14-21, and 23-26 remain pending in this 
application of which claims 1, 10 t 19, and 20 are independent. Claims 4, 13, and 22 
were canceled by a previous amendment. 

By this amendment, Applicant amends claims 1, 3, 5-7, 9-10, 12, 14-16, 18-19, 
20-21 , and 23-26 to further clarify Applicant's invention. Support for the claim 
amendments may be found in Applicant's specification. For example, with respect to 
ciaim 1 ; 

* Support for the addition of "each option being defined in the class or 
thorough a class inheritance hierarchy" can be found, for example, at page 
1 1 f lines 7-9. Here, the specification states, "if C itself contains a 
declaration of the option x, the binding associated with that declaration is 
used. If not, then if C's base class D has such a declaration, D's binding 

is used/ 1 

* Support for the addition of "each option having an option name and an 
option value associated therewith" can be found, for example, at page 10, 
line 1 3 ("Option names") and page 7, lines 2-3 ("If a class C of the Cur! 
language has a local option called y, the option's value can be 
accessed,.."). 

* Support for "option binding object generated by a compiler to describe 
each option" can be found in the exemplary embodiment of Fig. 2A 
(showing exemplary Option Binding objects in an exemplary option 
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binding list) and at page 13, fines 9-1 1 ('When these definitions are 
compiled, the compiler generates an OptionBinding object corresponding 
to each local-option declaration as illustrated at 30, 32, and 34 of Fig. 2A). 

• Support for "from the option name corresponding to the option value" can 
be found in the exemplary embodiment of Fig. 7A, which shows an 
exemplary "mapping data structure" and at page 21 lines 18-30, which 
describe the figure, 

• Support for "wherein code for the change handlers identified by the option 
biding object" may be found in the exemplary embodiment of Fig. 2A, 
which shows change-handlers associated with each of the 
OptionBindings. 

With respect to claim 6, for example; 

• Support for "a linked list of option items, each of the option items 
corresponding to a reference option comprising an option in the instance 
that has been referenced, and each of the option items having the option 
value and the option name corresponding to one of the referenced 
options" can be found in the exemplary embodiment of Fig. 2C, Fig. 2D 3 
and Fig. 2E, which show exemplary linked lists of option items, as well as 
at page 14, lines 17-28, which describe those figures. 

• Support for "when a first option is referenced in order to set a first option 
value for the first option, checking the listing data structure for a first option 
item corresponding to the first option; when the option item is found, 
setting the first option value in the first option item; and when no first 
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option item is found, creating the first option item, setting the first option 
value in the first option item, and storing the first option item with the first 
set option value in the listing data structure 7 ' can be found in the exemplary 
embodiment of Fig. 2C and Fig. 2D, which show exemplary linked lists of 
option items, as welt as at page 15, lines 1-3, which states, If another 
option for the color blue were added, the linked list would be extended as 
illustrated in Figure 2D. 
Other claims have been amended similarly to claims 1 and 6. Accordingly, no 
new matter has been introduced. In view of the foregoing amendments and the 
following remarks, Applicant respectfully traverses Examiner's rejections of claims 
under 35 US.C. § 102 and 35 US,C. §103. 

Additionally, Applicant notes that the submission of Amendments to the 
Specification on page 2 of the Response filed with the USPTO on November 3, 2006, 
have not been acknowledged. Applicant respectfully requests acknowledgment of 
those amendments. 

Double Patenting Rejection 

In the Office Action mailed January 26, 2007, claims 1-3, 5-12, 14-21 , and 23-26 
were rejected under the judicially created doctrine of obviousness-type double patenting 
as being unpatentable over claims 1-12 of U.S. Patent Application Publication No. US 
2002/100033 A1 (U.S. Application No. 09/759,697) and claims 1-12 of U.S. Patent 
Application Publication No. US 2002/0112229 (U.S. Application No. 09/760,031). 

While Applicant respectfully disagrees with the provisional obviousness-type 
double patenting rejection, filed herewith is a terminal disclaimer in compliance with 37 



CFR 1321, which overcomes the provisional obviousness-type double patenting 
rejection over claims 1-12 of copending Application No. 09/759,697 and claims 1-12 of 
copending Application No. 09/760,031. 

Rejections Under 35 U.S.C. § 102 

In the Office Action, claims 1, 3, 5-6, 9-10, 12, 14-15, 18-21, and 23-26 were 
rejected as being anticipated by McLennan, Michael J., "Object-oriented Programming 
with [incr Tel] Building Mega-Widgets with [incr Ik]," hereinafter McLennan . To properly 
establish that McLennan anticipates Applicant's claimed invention under 35 LLS,C. 
§ 102, each and every element of each of the claims in issue must be found, either 
expressly described or under principles of inherency, in that single reference. 
Furthermore, "[t]he identical invention must be shown in as complete detail as is 
contained in the ... claim/' See M.P.EP. § 2131, quoting Richardson v. Suzuki Motor 
Co., 868 F.2d 1126, 1236, 9 USP,Q.2d 1913, 1920 (Fed. Cir. 1989). Applicant 
submits that independent claim 1 is not anticipated by McLennan because the reference 
fails to teach each and every claim element of cfaim 1 . 

Specifically, McLennan does not disclose 

"notifying the Instance of a change in a selected option value through 
change handlers identified by an option binding object generated by a 
compiler to describe each option, the option binding object being located 
by first searching a mapping data structure for any previously computed 
mapping from the option name corresponding to the selected option 
value to the option binding object, and if no mapping was found, by then 
computing a mapping from the option name corresponding to the 
selected option value to the option binding object and storing the 
mapping in the mapping data structure," 

as recited in Applicant's claim 1. 

First, Applicant's "option binding object generated by a compiler to describe each 
option" is not analogous to the "background" and other configuration options shown in 



Mclennan 's figure 2-7 and 2-8, as the Office Action suggests, See Office Action at 6. 
The exemplary embodiment of Fig. 2A of Applicant's specification shows exemplary 
Option Binding objects identifying change handier code. The "background" of 
McLennan is not an "option binding object" because it is not generated by the compiler 
to describe the option. Nowhere does McLennan disclose "option binding objects 
generated by a compiler to describe each option," 

Further, Applicant's "mapping data structure" is not analogous to Mclennan 's 
"master list/' as the Office Action suggests. See Office Action at 6, An exemplary 
mapping data structure as shown in Applicant's Specification at Fig. 7A maps from an 
option name to an option binding object. Mclennan 's master list does not comprise a 
"mapping from the option name corresponding to the selected option value to the option 
binding object" because it does not map from the option name to the option binding 
object. Nowhere does McLennan disclose "a mapping data structure ...mapping from 
the option name corresponding to the selected option value." 

However, even if these elements were analogous, the Office Action fails to show 
where McLennan discloses If no mapping was found, ...then computing a mapping 
from the option name corresponding to the selected option value to the option binding 
object and storing the mapping in the mapping data structure," as recited in claim 1, 
The Office Action cites to pages 95-97 in McLennan as disclosing the aforementioned 
element of Applicant's claim. See Office Action at 6, However, at this reference, 
Mclennan does not refer to the "master list," nor does Mclennan disclose searching its 
"master list" for any previously computed mapping from the option name to the option 
binding object. McLennan especially does not disclose, as this reference or elsewhere, 
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what occurs when no mapping from the option name to the option binding object is 
found in the "master list," 

As noted above, McLennan fails to teach at least the recitation in claim 1 of, "if no 
mapping was found, .-.computing a mapping from the option name corresponding to the 
selected option value to the option binding object and storing the mapping in the 
mapping data structure." Independent claims 10, 19, and 20 recite similar elements. 
Accordingly, McLennan cannot anticipate claims 1, 10, 19, or 20, or claims 3, 5-6, 9, 12 f 
14-15, 18, and 21, which depend therefrom. 

Additionally, many of the dependent claims are allowable in their own right. For 
example, claim 6 refers to "a linked list of option items, each of the option items 
corresponding to a referenced option comprising an option in the instance that has been 
referenced." As disclosing this feature, the Office Action cites to McLennan at page 79, 
Figure 2-6 itk_option and associated text. See Office Action at 6. However, the 
itkj>ption is an array and not a linked list. See McLennan at 79 and Fig 2-6 (describing 
itk_option as an "array mapping option names to option values"). Moreover, McLennan 
nowhere discloses that the itk_option array would only comprise options that have been 
referenced. Lastly, McLennan discloses that when you create a component, the options 
for that component are added to the master list of options for the mega-widget {See 
McLennan at page 77, lines 1-2), but McLennan nowhere discloses, "when a first option 
is referenced in order to set a first option value for the first option, checking the listing 
data structure for a first option item corresponding to the first option; when the first 
option item is found, setting the first option value in the first option item; and when no 
first option item is found, creating the first option item, setting the first option value in the 
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first option item, and storing the first option item with the set first option value in the 
listing data structure/ 7 as recited by claim 6, For at least these additional reasons, 
McLennan does not disclose Applicant's claim 6. 

Applicant therefore respectfully requests the Examiner to reconsider and 
withdraw the rejection of claims 1, 3, 5-6, 9-10, 12, 14-15, and 18-21 as being 
anticipated by McLennan because McLennan does not disclose each and every 
element of Applicant's claims. 

Rejections Under 35 U.S.C. § 103 

In the Office Action, claims 2 and 1 1 were rejected as being anticipated by 
McLennan in view of Li et aL (US Patent No. 5, 943,496) hereinafter Li. Additionally in 
the Office Action, claims 7-8 and 16-17 were rejected as being anticipated by McLennan 
in view of Hostetter et al. "Curl: A Gentle Slope Language for the Web," World Wide 
Web Journal, Spring, 1997 (hereinafter Hostetter ). See Office Action at 8. 

Applicant respectfully traverses the rejection of claims 2, 7-8, 1 1 f and 16-17 
under 35 U.S.C, §103 as being obvious from McLennan in view of Li or from McLennan 
in view of Hostetter because a prima facie case of obviousness has not been 
established. To establish a prima facie case of obviousness, the prior art (separately or 
combined) must teach or suggest all the claim limitations. See M.P.E.P. § 2142, 8th 
Ed., Rev. 5 (August 2006). Moreover, "in formulating a rejection under 35 U.S.C, 
§ 103(a) based upon a combination of prior art elements, it remains necessary to 
identify the reason why a person of ordinary skill in the art would have combined the 
prior art elements in the manner claimed." USPTO Memorandum from Margaret A, 
Focarino, Deputy Commissioner for Patent Operations, May 3, 2007, page 2. A prima 
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facie case of obviousness has not been established because, among other things, the 
prior art, taken alone or in combination, fails to teach or suggest each and every 
element of claims 2, 7-8, 11, and 16-17, 

Claims 2 and 7-8 depend from claim 1, and claims 11 and 16-17 depend from 
claim 1 0, thus claims 2, 7-8, 1 1 , and 1 6-1 7 include all the elements and limitations of 
claims 1 and 10. Applicant respectfully submits that claims 1 and 10 contain recitations 
that are not disclosed in any of the references upon which the rejection under 
35 § 103 is based. As set forth above in the discussion of claims 1 and 10, 

McLennan fails to teach or suggest "if no mapping was found, ...computing a mapping 
from the option name corresponding to the selected option value to the option binding 
object and storing the mapping in the mapping data structure." The computing and 
restoring recitation of claims 1 and 10 is required by claims 2 7 7-8, 1 1 , and 16-17, 
Neither Li nor Hostetter make up for this deficiency of McLennan , since they also do not 
disclose or suggest "if no mapping was found, by then computing a mapping from the 
option name corresponding to the selected option value to the option binding object and 
storing the mapping in the mapping data structure." 

Applicant therefore respectfully traverses the rejection of claims 2 and 1 1 under 
35 U.S.C. §103 as being obvious from McLennan in view of Li and the rejection of 
claims 7-8 and 16-17 as being obvious from McLennan in view of Hostetter . 
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Please grant any extensions of time required to enter this response and charge 

any additional required fees to our deposit account 06-0916. 

Respectfully submitted, 

FSNNEGAN, HENDERSON, FARABOW, 
GARRETT & DUNNER, LLP. 



Dated: July 26, 2007 Bv: ■ ■■ --" '^-l ■ f ' ■ 



Maura K. Moian 
Reg. No. 31,859 
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